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Procedures for Maintaining the Time Zone Database 


Abstract 


Time zone information serves as a basic protocol element in 
protocols, such as the calendaring suite and DHCP. The Time Zone 
(TZ) Database specifies the indices used in various protocols, as 
well as their semantic meanings, for all localities throughout the 
world. This database has been meticulously maintained and 
distributed free of charge by a group of volunteers, coordinated by a 
single volunteer who is now planning to retire. This memo specifies 
procedures involved with maintenance of the TZ database and 
associated code, including how to submit proposed updates, how 
decisions for inclusion of those updates are made, and the selection 
of a designated expert by and for the time zone community. The 
intent of this memo is, to the extent possible, to document existing 
practice and provide a means to ease succession of the database 
maintainers. 


Status of This Memo 
This memo documents an Internet Best Current Practice. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


BCPs is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6557. 
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Copyright Notice 


Copyright (c) 2012 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


1. Introduction 


The IETF has specified several standards that make use of time zone 
information. Time zone names are used in DHCP to configure devices 
with correct local time [RFC4833]. Time zone names can appear in the 
TZID field of calendaring VEVENTs [RFC5545]. The normative reference 
for these values is the TZ Database [TZDB]. From the early 1980s 
through 2011, that database, which has been in use on nearly all UNIX 
systems, Java systems, and other sorts of systems, was hosted at the 
U.S. National Institutes of Health (NIH). The database consists of 
both historic and current entries for geographies throughout the 
world. Associated with the database is a reference implementation of 
ISO/IEC 9899 C [ISO09899C] and IEEE 1003.1 [IEEE1003.1] POSIX time 
functions that can be used to convert time values. 


The database was previously maintained by volunteers who participated 
in the <tz@elsie.nci.nih.gov> mailing list that was also hosted at 
the NIH. The database itself is updated approximately twenty times 
per year, depending on the year, based on information these experts 
provide to the maintainer. Arthur David Olson has maintained the 
database, coordinated the mailing list, and provided a release 
platform since the database’s inception. With his retirement now 
approaching, it is necessary to provide a means for this good work to 
continue. 


The time zone community has requested that the IETF adopt the ongoing 
maintenance of the Time Zone Database. The time zone community would 
like the IETF to maintain it in a consistent fashion to its 
administration of the Internet protocol parameters and values. 
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1.1. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


IANA (Internet Assigned Numbers Authority): For purposes of this 
RFC, IANA is a role, not an organization. The IANA Considerations 
defined in this RFC will be provided by the Internet Corporation 
for Assigned Names and Numbers (ICANN) in accordance with the 
TETF-ICANN "Memorandum of Understanding Concerning Technical Work 
of the Internet Assigned Numbers Authority", which was signed and 
ratified in March of 2000[RFC2860]. 


TZ Database: The Time Zone Database, sometimes referred to as the 
"Olson Database". This database consists of information about 
offsets from UTC for different localities, including daylight 
saving time (DST) transition information. 


TZ Coordinator: The person or people who maintain and manage release 
of the TZ Database. The TZ Coordinator also has responsibility 
for managing the TZ mailing list. The TZ Coordinator is an IANA 
Designated Expert, as defined in Section 3.2 of [RFC5226], except 
as regards to appeals, as discussed in Section 5 of this document. 
Roughly speaking, this means that the IESG will choose one or more 


experts to manage the TZ database, code, and mailing list. The TZ 
Coordinator will also lead work to develop appropriate service 
metrics. There SHALL be a single lead individual and at least one 


backup individual for this function. 


TZ mailing list: The forum where matters relating to the TZ database 
and supporting code are discussed. 


The rest of this document specifies the following: 
1. Transferring and maintenance of the TZ mailing list; 


2. Procedures for selecting a technical expert who will play the 
role of TZ Coordinator and release manager for the TZ database; 


3. Procedures for updating the TZ database; 
4. Maintenance and ownership of reference code; and 


5. Ownership of the database. 
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2. The TZ Mailing List 


For many years, the TZ mailing list has been the forum where 
discussion of changes to the TZ database and support files would take 
place. In addition, the TZ mailing list is used to announce releases 
of the database. Currently, the TZ mailing list is administered by 
the TZ Coordinator. 


This list membership, formerly at the NIH, has been transitioned to 


the IANA mail server. Its address, moving forward, is <tz@iana.org>. 
Subscriptions are processed at 
<https://mm.icann.org/mailman/listinfo/tz/>. The TZ Coordinator will 


continue to manage the list. While the TZ Coordinator may establish 
other rules of governance for the list, members of that list will be 
informed that a condition of participating on the list is that all 
contributions to the list are released to the public domain, and that 
by placing their contribution in the public domain, contributors 
waive forever any intellectual property claims. 


The list will be used just as it has been: to learn of, discuss, and 
confirm TZ definition changes, as well as to serve as an announcement 
list for new versions of the database. 


3. Making Updates to the TZ Database 


Updates to the TZ database are made by the TZ Coordinator in 
consultation with the TZ mailing list. The TZ Coordinator is 
empowered to decide, as the designated expert, appropriate changes, 
but SHOULD take into account views expressed on the mailing list. 


The TZ Coordinator will also decide the timing of database releases. 
Today, the release itself consists of several archive files that are 
downloaded from a well-known location. 


Moving forward, the TZ database, supporting code, and any appropriate 
supporting information SHOULD be cryptographically signed prior to 
release using well known public keys, along with any appropriate 
supporting information and distributed from 
<http://www.iana.org/time-zones>. 


The criteria for updates to the database include the following: 


1. New TZ names (e.g., locations) are only to be created when the 
scope of the region a name was envisioned to cover is no longer 
accurate. 
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2. In order to correct historical inaccuracies, a new TZ name MAY be 
added when it is necessary to indicate what was the consensus 
view at a given time and location. Such TZ names are usually not 


added when the inaccuracy was prior to 1970. 


3. Changes to existing entries SHALL reflect the consensus on the 
ground in the region covered by that entry. 


To be clear, the TZ Coordinator SHALL NOT set time zone policy for a 
region but use judgment and whatever available sources exist to 
assess what the average person on street would think the time 
actually is, or in case of historical corrections, was. 


4. Selecting or Replacing a TZ Coordinator 


From time to time it will be necessary to appoint a new TZ 
Coordinator. This could occur for a number of reasons: 


o The TZ Coordinator is retiring (as Arthur David Olson is) or has 
announced that he or she will be unable to continue to perform the 
function; 


o The TZ Coordinator is missing, has become incapacitated, or has 
died; or 


o The TZ Coordinator is not performing the function in accordance 
with community wishes. 


In any of these cases, members of the community should raise the 
issue on the TZ mailing list and attempt to reach consensus on a new 
candidate to fulfill the role of TZ Coordinator. If rough consensus 
cannot be reached easily, the Area Directors of the IETF Applications 
Area should attempt to guide the members of the community to rough 
consensus. The candidate that is agreed upon by the community 
through rough consensus shall be presented to the IESG for 
confirmation. If rough consensus cannot be reached, even with 
guidance from the Applications Area Directors, the IESG shall use 
whatever means it has at its disposal to choose a candidate who in 
its best judgment will be able to fulfill the role of TZ Coordinator. 


5. Appealing Database Decisions 


The TZ Coordinator makes decisions based on expertise, as well as 
with guidance from the TZ mailing list. If a member of the community 
has a concern with an individual decision made by the TZ Coordinator 
with regard to the TZ database, the individual shall proceed as 
follows: 
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6. 


1. Attempt to resolve the concern directly with the TZ Coordinator. 


2. If a resolution cannot be reached directly with the TZ 
Coordinator, express the concern to the community and attempt to 
achieve rough consensus regarding a resolution on the TZ mailing 
list. The Area Directors of the IETF Applications Area may at 
their discretion attempt to guide the members of the community to 
rough consensus. 


3. As a last resort, if a resolution cannot be reached on the TZ 
mailing list, appeal to the IESG for a resolution. The appellant 
must show that the decision made by the TZ Coordinator (a) was 
materially in error and (b) has caused material harm. [In its 
deliberations regarding an appeal, the IESG shall weigh all the 
evidence presented to it and use its best judgment in determining 
a resolution. 


Maintenance and Distribution of Reference Code 


Currently, the maintainer of the TZ database also maintains reference 
code, most of which is public domain. The reference implementation 
shall be distributed along with an associated cryptographic signature 
verifiable by a public key. Several files from this software are 
currently distributed under license. Where they exist, licenses 
SHALL NOT be changed. 


Database Ownership 


The TZ database itself is not an IETF Contribution or an IETF 
document. Rather it is a pre-existing and regularly updated work 
that is in the public domain, and is intended to remain in the public 
domain. Therefore, BCPs 78 [RFC5378] and 79 [RFC3979] do not apply 
to the TZ Database or contributions that individuals make to it. 
Should any claims be made and substantiated against the TZ Database, 
the organization that is providing the IANA Considerations defined in 
this RFC, under the memorandum of understanding with the IETF, 
currently ICANN, may act in accordance with all competent court 
orders. No ownership claims will be made by ICANN or the IETF Trust 
on the database or the code. Any person making a contribution to the 
database or code waives all rights to future claims in that 
contribution or in the TZ Database. 


TANA Considerations 
This section documents the following IANA actions: 


o Assistance on request of the IESG in selection of the TZ 
Coordinator, based on the procedures set forth above. 


Lear & Eggert Best Current Practice [Page 6] 


RFC 6557 Maintaining the Time Zone Database February 2012 


10. 


11. 


das. 


o Maintenance of a repository for the TZ database and associated 
reference code. The TZ Coordinator SHALL be named by the IESG as 
described above, and will act as the maintainer of the database 
and code, as described above. 


o Creation of appropriate access for the TZ Coordinator to maintain 
the database, as well as necessary tooling that may be required, 
so long as no direct software costs are incurred. 


o Establishment of security of the system upon which the database 
resides. Both current and historical versions of the database 
will be stored and distributed via HTTP/HTTPS. 


o Maintenance of a cryptographic private key that is used to sign 
the database and that will survive a change of TZ Coordinator. 


Security Considerations 


The distribution of the database is currently not secured. This memo 
states that the TZ database SHOULD be distributed with a valid 
cryptographic signature moving forward. 
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